Nautilus 1992 July/Nautilus-3-8/Nautilus-3-8.bin/Tools & Utilities/Techy Stuff/Doco ƒ/CSMP ƒ/CSMP-V1-098.TXT

Text File | 1992-06-30 | 31.7 KB | 771 lines

C.S.M.P. Digest             Thu, 28 May 92       Volume 1 : Issue 98

Today's Topics:

    cute diskdrive icons
    PwrBk 100 missing 32Bit QD?
    AppleEvents over the network.
    How can I rotate a PICT?
    MPW C++ question (bug?)


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu.  This is also the home of the comp.sys.mac.programmer Frequently Asked
Questions list.  The last several issues of the digest are available from
sumex-aim.stanford.edu as well.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The digest is a collection of articles from the internet newsgroup comp.sys.
mac.programmer.  It is designed for people who read c.s.m.p. semi-regularly
and want an archive of the discussions.  If you don't know what a newsgroup
is, you probably don't have access to it.  Ask your systems administrator(s)
for details.  (This means you can't post questions to the digest.)

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (Etienne Bido)
Subject: cute diskdrive icons
Date: 13 Apr 92 23:48:45 GMT
Organization: VU Biology, Amsterdam, The Netherlands

I' ve noticed that when using some apps. or DA's there are two icons
for the internal and external drive. I like those icons because they
show which disk is in the internal/external drive.
Is there a way to have the finder automatically use those icons when
you insert a disk?
I've been looking for them but I can't find those icons in the system
or he finder. Where are they stored?
I know that you can give each disk a different icon but they keep
that icon whether you put the disk in the int. or the ext. drive.

thanx!

- --
Etienne Bido            |[e-mail]
Vrye Universiteit        |[e-mail]
Amsterdam
The Netherlands

+++++++++++++++++++++++++++

From: [e-mail] (Ray Arachelian)
Date: 21 Apr 92 16:35:00 GMT
Organization: FidoNet node 1:2603/204 - Not Even Odd, Forest Hills NY

On 04-14-92, [e-mail] wrote to ALL:

 E> I' ve noticed that when using some apps. or DA's there are two icons
 E> for the internal and external drive. I like those icons because they
 E> show which disk is in the internal/external drive. Is there a way to
 E> have the finder automatically use those icons when you insert a disk?

Nope.  Not unless you want to write your own INIT or CDEV that does this.

As for the icons themselves, using ResEdit to open the System file or
Finder, as you've said doesn't give them away.  I've a feeling that they
might be device dependant.  But if you can capture the screen when these
show up, then you can cut them out of the PICT file and build your own
icons.  Still you'd need an INIT to display them...

As a matter of fact, I've done you the favor of capturing the external
drive icon.  (I don't have an internal drive because I build my own Mac
IIcx, "Hackintosh IIcx" if you will, and at the time I couldn't find a
decently priced Superdrive.   Go into ResEdit, create a new resource of
ICON type, then close the icon editor, open that resource with the hex
editor, select all, and paste these hex numbers on top of it:

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 10 00 00 00 10 FF FF FC 10 80 00 04 10 FF FF
FC 7C 80 00 04 38 FF FF FC 10 80 01 F4 00 A0 00 05 FF 80 00 05 01 FF FF FD
7D 80 00 05 01 FF FF FD FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00


 * Freddie 1.2b7 * You have been found guilty of commerce with the devil.

- --
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
 Ray Arachelian - Internet: [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Jeremiah Blatz)
Date: 25 Apr 92 20:36:31 GMT
Organization: Dartmouth College, Hanover, NH

On 04-14-92, [e-mail] wrote to ALL:

 E> I' ve noticed that when using some apps. or DA's there are two
icons
 E> for the internal and external drive. I like those icons because
they
 E> show which disk is in the internal/external drive. Is there a way
to
 E> have the finder automatically use those icons when you insert a
disk?

If you're using pre-Sys. 7, you can easily do this. Just open the
Finder w/ResEdit, and open the "LAYO" resc. Scroll down until you see
"use phys. icons," or something like that. Set that bit to true. Save &
Quit, it's as easy as that. I think you need to restart.

Hope this helps,
Jeremiah

+++++++++++++++++++++++++++

From: [e-mail] (Etienne Bido)
Date: 27 Apr 92 11:13:42 GMT
Organization: VU Biology, Amsterdam, The Netherlands

E> I' ve noticed that when using some apps. or DA's there are two
icons
 E> for the internal and external drive. I like those icons because
they
 E> show which disk is in the internal/external drive. Is there a way
to
 E> have the finder automatically use those icons when you insert a
disk?

If you're using pre-Sys. 7, you can easily do this. Just open the
Finder w/ResEdit, and open the "LAYO" resc. Scroll down until you see
"use phys. icons," or something like that. Set that bit to true. Save &
Quit, it's as easy as that. I think you need to restart.

Hope this helps,
Jeremiah

=====================
Thanx to all the people who send me this tip.
But (un)fortunately I'm running sys 7, and the finder doesn't have a LAYO
resc.
How can you do this in System 7?

- --
Etienne Bido            |[e-mail]
Vrye Universiteit        |[e-mail]
Amsterdam
The Netherlands

---------------------------

From: [e-mail] (Roy Richter)
Subject: PwrBk 100 missing 32Bit QD?
Date: 27 Apr 92 12:36:41 GMT
Organization: GM Research, Warren, Mi

Or am I missing something?  I assumed that since the PowerBook 100 was
running System 7.0.1, that it would have the latest version of Quickdraw.
Unfortunately, when I check using the Gestalt call ,the answer I get back
is 0, that it is running the original version.

Is it me or the machine?  (and of course, why?)
- --
Roy Richter                  Internet: [e-mail]
Physics Dept, GM Research    UUCP:     rphroy!rrichter

+++++++++++++++++++++++++++

From: [e-mail] (Paul Potts)
Date: 27 Apr 92 13:27:27 GMT
Organization: Instructional Technology Laboratory, University of Michigan

In article <[e-mail]> [e-mail] (Roy Richter) writes:
>Or am I missing something?  I assumed that since the PowerBook 100 was
>running System 7.0.1, that it would have the latest version of Quickdraw.
>Unfortunately, when I check using the Gestalt call ,the answer I get back
>is 0, that it is running the original version.
>
>Is it me or the machine?  (and of course, why?)

It is the machine. Yes, the PB 100 doesn't have color QuickDraw or
32-bit QuickDraw. Color QuickDraw uses instructions and addressing modes
only available on the 68020 or better processor. It might be possible to
write color QuickDraw to use only 68000 instructions, but it would run so
slowly as to be not worth the effort. So, you can't use GWorlds or PixMaps
on a PB100. On a 68000-based machine, though, you really wouldn't want to -
things would be painfully slow.

The PB100 is a black-and-white machine - why do you need color QuickDraw on
it? If you are writing an application that should run on older Macs, like
the SE and Plus, you will need to operate using Classic QuickDraw as well.
If your color needs are minimal, you can use the original 8 QuickDraw colors -
this will appear in color on a color machine, and in black and white on a
B&W machine.

If your app just can't run without color QD, you can always issue a polite
message like "get a real Mac, bub" and exit.

- --
Paul Potts - [e-mail]
Un damne' descendant sans lampe,/ Au bord d'un gouffre dont l'odeur
Trahit l'humide profondeur,/ D'e'ternels escaliers sans rampe...
   -Baudelaire on DOS/Windows programming

+++++++++++++++++++++++++++

From: [e-mail] (Richard Clark)
Date: 27 Apr 92 16:07:25 GMT
Organization: Apple Computer Inc., Cupertino, CA

Roy --

  Like QuickTime, 32-Bit Quickdraw requires a 68020 or later (it requires some
instructions and addressing modes not available on the original 68000.) Since
the Powerbook 100 contains a 68000, 32-Bit Quickdraw will not run on this
machine.

...Richard

- --
Richard Clark   Instructor/Course Designer, Developer University    Apple Comp.
- --
Richard Clark   Instructor/Course Designer, Developer University    Apple Comp.

---------------------------

From: [e-mail] (Levent Mollamustafaoglu)
Subject: AppleEvents over the network.
Date: 26 Apr 92 21:30:31 GMT
Organization: Aiken Computation Lab, Harvard University

I've done a considerable amount of programming with MacApp and Think
Pascal on the Mac, but I have not started with System 7 applications
yet, so I need some help from OOP/AppleEvents gurus.

I have a discrete-event simulation program that runs on a parallel
machine, the Maspar MP-1. The algorithm I use is especially suitable
for parallel/distributed simulation since it does not require extensive
communication between processors. One processor which runs the main
engine generates lots of random numbers and transfers those numbers
to other processors which do the dirty simulation work. On a parallel
machine, this is very easy.

I am planning to implement the same idea on an Appletalk network and
considering the possibility of using some network-wide Apple events.
Since the code will be object-oriented and I am planning to write it
with Think Pascal and TCL, the communication should be in the form of
a message that can be conveyed through a network-wide Apple event
(though it can also be done by sending individual messages to each
remote program) and activates a method of an object in the remote
program. The message can be followed by a block of data.

I wonder whether there is a way to send AppleEvents transparently.
namely, I can send a particular event to a number of applications,
some of which can be local, and some residing on other Macs on the
network.

If some of the ideas summarized above trivially coincide with
already existing methods, I would be very glad if you can give some
pointers. (Inside Mac VI is a huge book, and not always that clear)


===========================================================================
Dr. Levent Mollamustafaoglu       Harvard University
[e-mail]    [e-mail]
===========================================================================

+++++++++++++++++++++++++++

From: [e-mail] (Richard Clark)
Date: 27 Apr 92 16:00:46 GMT
Organization: Apple Computer Inc., Cupertino, CA

[e-mail] (Levent Mollamustafaoglu) writes:

>I am planning to implement the same idea on an Appletalk network and
>considering the possibility of using some network-wide Apple events.

  Since the Apple event manager uses AppleTalk as the transport medium, you
cannot "broadcast" an Apple event. Your only option is to send the event
serially to each receiver.

>I wonder whether there is a way to send AppleEvents transparently.
>namely, I can send a particular event to a number of applications,
>some of which can be local, and some residing on other Macs on the
>network.

  Yes, you can, using the "TargetID" address format. TargetIDs are valid for
processes on the same machine as the sender or for processes running anywhere
in the network.

  Fortunately, the "IPCListPorts" call will help you find the addresses of
other processes on the network. You specify a NBP-style lookup record , and
IPCListPorts searches the network and returns a list of TargetIDs.

  Hope this helps.

...Richard
- --
End user scripting: Hopeful programmers' fantasy that, deep inside, users are
                    just like them.

---------------------------

From: [e-mail] (Lars Petrus)
Subject: How can I rotate a PICT?
Date: 14 Apr 92 14:01:27 GMT
Organization: Stacken Computer Club, Stockholm, Sweden


   I have a PICT that is read from a resource. How can I rotate it
in memory or at least display it rotated? I'm only interested in
90 degree intervals, so no fancy mathematics is needed.


"Madness is the first sign of dandruff" |   Email:   [e-mail]
   - Dr Winston O'Boogie                |   Reality: Lars Petrus, Solna, Sweden

+++++++++++++++++++++++++++

From: [e-mail] (Eric Aubourg)
Date: 24 Apr 92 14:02:01 GMT
Organization: Ecole Normale Superieure, PARIS, France

In article <[e-mail]> [e-mail] (Lars Petrus) writes:
>
>   I have a PICT that is read from a resource. How can I rotate it
>in memory or at least display it rotated? I'm only interested in
>90 degree intervals, so no fancy mathematics is needed.
>
>
>"Madness is the first sign of dandruff" |   Email:   [e-mail]
>   - Dr Winston O'Boogie                |   Reality: Lars Petrus, Solna, Sweden

Look on ftp.apple.com. There is a file rotate-bitmap-90-degrees.hqx
I think it's in mac/sc/snippets/graphics.printing/quickdraw

Eric

---------------------------

From: [e-mail] (J.T. Teh)
Subject: MPW C++ question (bug?)
Date: 23 Apr 92 21:15:02 GMT
Organization: Borland International, Inc.

What's wrong with this MacApp/C++ code?
GetItem and OpenDeskAcc uses the definitions from MacApp's include
files.

Str255 daName;
GetItem(menuID, itemID, daName);
OpenDeskAcc(daName);

where menuID and itemID are obtained from the event record. CFront
generates code to copy daName to a temporary CStr255 and passes
the record to GetItem. However it never copies the string passed back
from GetItem to daName. So, OpenDeskAcc never gets the right string
passed back from GetItem.

Is the above a bug? Thanks.

- -J.T.

BTW, declaring daName as a CStr255 works correctly.

- ----------------------------------------------------------------------
J.T. Teh          Borland International Inc.     [e-mail]
                                                       MCI Mail: JTTEH

                   " WILL  CODE  FOR  FOOD ! "

- ----------------------------------------------------------------------

+++++++++++++++++++++++++++

From: [e-mail] (Mark Lanett)
Date: 25 Apr 92 16:18:56 GMT
Organization: University of Illinois at Urbana

[e-mail] (J.T. Teh) writes:

>What's wrong with this MacApp/C++ code?
>GetItem and OpenDeskAcc uses the definitions from MacApp's include
>files.

!$@#!%@#!$% There is nothing wrong with CFront, you know that the answer is to
declare it a CStr255, so why are you calling it a bug!? I swear, *everybody*
rather than reading the ARM, just goes and calls something they don't understand
a compiler bug. It drives me up the %@$^%$# wall.

Would you expect this to work:
foo(char*);
int* i; foo(i);

No, of course not, the pointers are not compatible. So why do you expect passing
a Str255& to a routine that takes a CStr255& to work? A reference is a pointer.
*Because* it's a reference, the compiler can generate temporaries. Yes, it's
stupid that the language doesn't take the temporary and try to assign it back,
but this is described in the ARM. It's also very stupid that MPW CFront doesn't
see fit to warn you about this situation unless you turn on -w1, in which case
it also prints out 2 billion other totally stupid meaningless warnings. It's
also really stupid that the MacApp team can't make up their minds what they want
to call things, and have gone and renamed the String class CStr255 even though
for ages I've typed "Str255" and there *is* a Str255 class but you need to use
a CStr255 everywhere and the compiler doesn't complain if you accidentally use
a Str255 but the code doesn't work. I'm just going to have to work for Apple and
kick and scream until they get a clue and quit doing these stupid totally
arbitrary things and start using the talent that I know is there because it
occasionally accidentally shows up.

But I really, really, really wish peaple would read the ARM or C++ v2.0 before
posting things like 'Surprise, a bug in C for ANY compiler' when they are
acting stupid with scanf, or references, or... Reading it -- or Stroustrup's
2.0 edition, which is quite good -- is a smart idea anyway. I'm totally willing
to explain obscure parts of the language to others, but it gets tiring real fast
when they come to me first rather than looking it up. How do you expect to
learn the language?

My rule of thumb: It's never, ever a compiler bug. It's not a MacApp bug. It's
my bug and I'm a total moron for not realizing it immediately. So I make *damn*
sure it's not because I'm a stupid fool who shouldn't be programming, and when
I've read the assembly and ARM several times, *then* I can blame someone else.
- --
Mark Lanett, Software Tools Group, NCSA; [e-mail]; NCSA.STG (AppleLink)

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Organization: Kalamazoo College
Date: Sat, 25 Apr 1992 19:04:11 GMT

Mark Lanett writes:
>
>!$@#!%@#!$% There is nothing wrong with CFront, you know that the answer is to
>declare it a CStr255, so why are you calling it a bug!? I swear, *everybody*
>rather than reading the ARM, just goes and calls something they don't
>understand a compiler bug. It drives me up the %@$^%$# wall.
>
[30 lines deleted]
>
>So I make *damn*
>sure it's not because I'm a stupid fool who shouldn't be programming, and when
>I've read the assembly and ARM several times, *then* I can blame someone else.

Aren't you being a little hard on J.T.?  S/he was questioning whether
it was a bug, not stating that it was.  Programmers, in this forum
at least, are allowed to try to learn without being implicitly called
"stupid fools."

If novice programmers' questions really drive you up the %@$^%$# wall,
maybe you should stop reading c.s.m.p.
- --
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 Glass of milk / Standing in between extinction in the cold
 And explosive radiating growth

+++++++++++++++++++++++++++

From: [e-mail] (Mark Lanett)
Organization: University of Illinois at Urbana
Date: Sat, 25 Apr 1992 22:20:17 GMT

[e-mail] (Jamie R. McCarthy) writes:

>Aren't you being a little hard on J.T.?  S/he was questioning whether
>it was a bug, not stating that it was.  Programmers, in this forum
>at least, are allowed to try to learn without being implicitly called
>"stupid fools."

>If novice programmers' questions really drive you up the %@$^%$# wall,
>maybe you should stop reading c.s.m.p.

I've nothing against novice questions, just the ones that can be easily answered
by one's local C++ book. UseNet should be a place to go for last resort or
clarification. And I consider 'last resort' a relative term; in the case of,
say, MABuild internals, I would not wish upon anyone the need to read the source
code. And Apple has made the reference question likely to pop up with their
3.0b3 changes to MacApp. But it *is* something that is documented.

Mark L
- --
Mark Lanett, Software Tools Group, NCSA; [e-mail]; NCSA.STG (AppleLink)

+++++++++++++++++++++++++++

From: [e-mail] (Peter Lau)
Organization: State University of New York at Albany
Date: 25 Apr 92 19:40:28

In article <mlanett.704240417@void> [e-mail] (Mark Lanett)
writes:

>   I've nothing against novice questions, just the ones that can be easily answered
>   by one's local C++ book. UseNet should be a place to go for last resort or
>   clarification. And I consider 'last resort' a relative term; in the case of,
>   say, MABuild internals, I would not wish upon anyone the need to read the source
>   code. And Apple has made the reference question likely to pop up with their
>   3.0b3 changes to MacApp. But it *is* something that is documented.

Just want to comment on the above statements. I think
the degree of difficulty of a question depends on the
knowledge of the person who ask the question. The question
might be easy to you but might not be easy to someone else.

If you don't want to help, hit the 'n' key and forget about
the posting. At least that could keep your blood pressure low
and save the energy to debug your stuffs.  :-)

pete

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 27 Apr 92 02:53:27 GMT
Organization: MacDTS Mongols

In article <mlanett.704218736@void>, [e-mail] (Mark Lanett)
writes:
> No, of course not, the pointers are not compatible. So why do you expect
passing
> a Str255& to a routine that takes a CStr255& to work? A reference is a
pointer.
> *Because* it's a reference, the compiler can generate temporaries. Yes, it's
> stupid that the language doesn't take the temporary and try to assign it back,
> but this is described in the ARM. It's also very stupid that MPW CFront
doesn't
> see fit to warn you about this situation unless you turn on -w1, in which case
> it also prints out 2 billion other totally stupid meaningless warnings. It's
> also really stupid that the MacApp team can't make up their minds what they
want
> to call things, and have gone and renamed the String class CStr255 even though
> for ages I've typed "Str255" and there *is* a Str255 class but you need to use
> a CStr255 everywhere and the compiler doesn't complain if you accidentally use
> a Str255 but the code doesn't work. I'm just going to have to work for Apple
and
> kick and scream until they get a clue and quit doing these stupid totally
> arbitrary things and start using the talent that I know is there because it
> occasionally accidentally shows up.

Well, I tried to make them call all these new stack-based functions with
a starting T, like in TStr255 :-). They really wanted to point out that certain
classes are stack-based, so they used prefix C for that. And they didn't want
to confuse programmers more with having the same name for a struct and a
utility class - which DTS also considered to be a wise thing.

Note that all these MacApp utility classes are not officially sanctioned
as the C++ interface definition, this is only something that MacApp has,
and it's not sure it will be a C++ convention at all. I hope not, because
I don't want to maintain more than one-two header file sets. Otherwise we
could introduce more bugs.

> But I really, really, really wish peaple would read the ARM or C++ v2.0 before
> posting things like 'Surprise, a bug in C for ANY compiler' when they are
> acting stupid with scanf, or references, or... Reading it -- or Stroustrup's
> 2.0 edition, which is quite good -- is a smart idea anyway. I'm totally
willing
> to explain obscure parts of the language to others, but it gets tiring real
fast
> when they come to me first rather than looking it up. How do you expect to
> learn the language?

You must understand that there are many newcomers to C++ that don't know about
all the tricks of the trade. Be patient, they will learn! Otherwise I agree
that there's a lot of good literature out there, the buzzword C++ has created
a lot of books. ARM should be one of the standard reference books in every
bookshelf,
I would estimate that I have answered about 200-300 DTS C++ questions just by
looking up the answer in ARM, hehe...


Cheers,
Kent

+++++++++++++++++++++++++++

From: [e-mail] (Matthias Ulrich Neeracher)
Date: 27 Apr 92 12:12:10 GMT
Organization: Integrated Systems Laboratory, ETH, Zurich

In article <mlanett.704218736@void> [e-mail] (Mark Lanett) writes:
>[e-mail] (J.T. Teh) writes:
>
>>What's wrong with this MacApp/C++ code?
>>GetItem and OpenDeskAcc uses the definitions from MacApp's include
>>files.
>
>!$@#!%@#!$% There is nothing wrong with CFront, you know that the answer is to
>declare it a CStr255, so why are you calling it a bug!? I swear, *everybody*
>rather than reading the ARM, just goes and calls something they don't understand
>a compiler bug. It drives me up the %@$^%$# wall.

While I generally agree with these feelings...

>So why do you expect passing
>a Str255& to a routine that takes a CStr255& to work? A reference is a pointer.
>*Because* it's a reference, the compiler can generate temporaries. Yes, it's
>stupid that the language doesn't take the temporary and try to assign it back,
>but this is described in the ARM.

... I wonder whether whether *you* have read the ARM passage relevant to this
question. To quote from the ARM, section 8.4.3, pages 154--155 in my edition:

******* Begin ARM quote, emphasis is mine ***********************************

If the initializer for a reference to type T is an lvalue of type T or of a
type derived (@10) from T for which T is an accessible base (@4.6), the reference
will refer to the initializer; otherwise, IF AND ONLY IF THE REFERENCE IS TO A
CONST an object of type T will be created and initialized with the initializer.
The reference then becomes a name for that object. For example,

   double d = 1.0;

   double & rd = d;                          // rd refers to `d'
   const double & rcd = d;                   // rcd refers to `d'

   double & rd2 = 1;                         // error: type mismatch
   const double & rcd2 = 1;                  // rcd2 refers to temporary
                                             // with value `1'

[Comment section]
The distinction between references to consts and references to non-consts is a
major change from earlier definitions of C++. The distinction was made to
eliminate a major source of errors and surprises. Earlier, all references could
be initialized to refer to temporary objects ao all the initializations above
were legal.
Naturally, this feature will be faded out of implementations slowly, to avoid
breaking working code.

******** End ARM quote *****************************************************

So, according to the ARM, what J.T. was trying to do is supposed *not to work
at all*, not to silently fail. The behavior of the CFront version that Apple
currently uses is to be considered at least an anachronism and could even be
called a bug.

>My rule of thumb: It's never, ever a compiler bug. It's not a MacApp bug. It's
>my bug and I'm a total moron for not realizing it immediately. So I make *damn*
>sure it's not because I'm a stupid fool who shouldn't be programming, and when
>I've read the assembly and ARM several times, *then* I can blame someone else.

Agreed. And while we're at it, never claim it's a virus either before having
taken the above steps. Still, there *are* sometimes compiler bugs, there *are*
compiler anachronisms, and there *are* computer virii.

Matthias

- -----
Matthias Neeracher                                   [e-mail]
   "Have you heard of the new Cambridge compilers ? They distribute
    gear-wear much more evenly"
        -- William Gibson/Bruce Sterling, _The Difference Engine_

+++++++++++++++++++++++++++

From: [e-mail] (Mark Lanett)
Date: 27 Apr 92 14:32:32 GMT
Organization: University of Illinois at Urbana

[e-mail] (Kent Sandvik) writes:

>In article <mlanett.704218736@void>, [e-mail] (Mark Lanett)
>writes:
>> also really stupid that the MacApp team can't make up their minds what they
>want
>> to call things, and have gone and renamed the String class CStr255 even though
>> for ages I've typed "Str255" and there *is* a Str255 class but you need to use
>> a CStr255 everywhere and the compiler doesn't complain if you accidentally use
>> a Str255 but the code doesn't work. I'm just going to have to work for Apple
>and
>> kick and scream until they get a clue and quit doing these stupid totally
>> arbitrary things and start using the talent that I know is there because it
>> occasionally accidentally shows up.

>Well, I tried to make them call all these new stack-based functions with
>a starting T, like in TStr255 :-). They really wanted to point out that certain

That wouldn't be too confusing :-) In one program I used T for classes
*written* in Pascal and C for C++ ones (but PascalObject-descended), which
is yet another way to confuse other people reading your code. Now I've given
up and use no conventions at all. Since everyone has different conventions I
figure this will maximize the discomfort in reading my code. I've also been
known to switch conventions, sometimes in the same class.

>classes are stack-based, so they used prefix C for that. And they didn't want
>to confuse programmers more with having the same name for a struct and a
>utility class - which DTS also considered to be a wise thing.

I'd argue that 1) you *want* Str255 turned into a class (what good is
a char array?) and 2) It should keep the Str255 name because that's what the
"string" structure has always been called. It's much less confusing if the
data structure for strings is just called Str255, whatever the features. It's
called the same thing in Pascal and C, even though it acts quite different; I
would think Str255 would make more sense, with the C++ version actually
being closer to the Pascal one.
- --
Mark Lanett, NCSA Software Development                         [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Mark Lanett)
Date: 27 Apr 92 17:20:03 GMT
Organization: University of Illinois at Urbana

[e-mail] (Matthias Ulrich Neeracher) writes:

>******* Begin ARM quote, emphasis is mine ***********************************

>If the initializer for a reference to type T is an lvalue of type T or of a
>type derived (@10) from T for which T is an accessible base (@4.6), the reference
>will refer to the initializer; otherwise, IF AND ONLY IF THE REFERENCE IS TO A
>CONST an object of type T will be created and initialized with the initializer.
>The reference then becomes a name for that object. For example,

>   double d = 1.0;

>   double & rd = d;                          // rd refers to `d'
>   const double & rcd = d;                   // rcd refers to `d'

>   double & rd2 = 1;                         // error: type mismatch
>   const double & rcd2 = 1;                  // rcd2 refers to temporary
>                                             // with value `1'

>[Comment section]
>The distinction between references to consts and references to non-consts is a
>major change from earlier definitions of C++. The distinction was made to
>eliminate a major source of errors and surprises. Earlier, all references could
>be initialized to refer to temporary objects ao all the initializations above
>were legal.
>Naturally, this feature will be faded out of implementations slowly, to avoid
>breaking working code.

>******** End ARM quote *****************************************************

>So, according to the ARM, what J.T. was trying to do is supposed *not to work
>at all*, not to silently fail. The behavior of the CFront version that Apple
>currently uses is to be considered at least an anachronism and could even be
>called a bug.

AT&T C++ 3.0 accepts these constructs but generates a warning. Under +p (pure)
it *is* considered an error.
g++ 2.1 accepts it and doesn't print any warnings, even with -Wall.
I believe CFront will generate an error for this situation under full warnings.
It doesn't complain at all by default, though.
- --
Mark Lanett, NCSA Software Development                         [e-mail]

---------------------------

End of C.S.M.P. Digest
**********************